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METHOD AND APPARATUS FOR FAOLITATING ONLINE PAYMENT 
TRANSACTIONS IN A NETWORK-BASED TRANSACTION FACILITY USING 
MULTIPLE PAYMENT INSTRUMENTS 

This present application claims the benefit of the filing date of U.S. 
provisional patent application no. 60/190,420, filed March 17, 2000. 

FIELD OF THE INVENTION 

The present invention relates generally to the field of e-commerce and, more 
specifically, to facilitating online payment traiisactions in a network-based 
transaction fadlity using multiple payment instructions. 

BACKGROUND OF THE INVENTION 

For users of a network-based transaction facility, a reliable and convenient 
payment mechanism is particularly important for enhancing user trust in the 
transaction facility. A typical network-based transaction facility, however, does not 
ensure the expedient and secure completion of payment transactions. Instead, 
payment transactions between traders of an online trading community are typically 
conducted in a conventional, time-constiming manner using paper checks and 
money orders. Accordingly, such payment transactions delay payments to sellers 
and delivery of purchased goods to buyers. In addition, sellers are expected to bear 
the risk of bounced checks and buyers are running the risk of not receiving the 
goods after sending the money. 

The above problems are typically faced by individuals or smaU businesses 
who cannot afford to build or buy the infrastructure to accept credit card payments 
from buyers in the network-based transaction facility. However, even a seller who 
does accept credit card payments can still lose those buyers who appreciate the 
convenience of online payments but do not have access to credit cards. In addition, 
a buyer may prefer not to disclose his or her credit card information over the 
Internet in general, or to a certain seller ia particular. Further, credit card payments 
may not always be desirable for sellers because of their charge back recourse to 
buyers. 
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Therefore, it will be advantageous to provide traders with an efficient and 
secure mechanism for facilitating online payment transactions via a variety of 
payment instruments. 
SUMMARY OF THE INVENTION 

A method and apparatus for facilitating online payment transactions between 
participants in a network-based transaction facility are described. In one 
embodiment, user interface information is commimicated to a first participant via a 
communications network. The user interface information identifies various pajnnent 
instruments available for processing the online payment transactions in the network- 
based transaction fadLity. Further, payment option information is received from the 
first participant via the communications network. The pa5nTient option information 
indicates the willingness of the first participant to accept a payment from a second 
participant via one or more of the various payment instrimients. This payment 
option information is passed to the second participant via the commvmications 
network. Afterwards, personal billing information is accepted from the second 
participant via the communications network to facilitate an online payment 
transaction between the first participant and the second participant. The personal 
billing information concerns a payment instrument selected by the second 
participant from the payment instruments specified by the first participant. 
BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example and not limitation in 
the figures of the accompanying drawings, in which like references indicate similar 
elements and in which: 

Figure 1 is a block diagram of one embodiment of a system for processing 
online payment transactions between participants in a network-based transaction 
facility; 

Figure 2 is a block diagram of one embodiment of a network-based 
transaction facifity; 

Figure 3 is a block diagram of one embodiment of an online payment service; 
Figure 4 is a block diagram of an exemplary online payment service 
supporting multiple data centers; 
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Figure 5 is a flow chart of ar\ exemplary method for facilitating online 
payment transactions using multiple payment instruments; 

Figure 6 is a block diagram of one embodiment of a database maintained by 
an online payment service; 

Figure 7 is a block diagram of one embodiment of a process flow for 
evaluating risks involved in an online payment transaction; 

Figure 8 is a block diagram of one embodiment of an interface sequence 
implemented to facilitate online payment trarisactions through multiple payment 
instruments; 

Figure 9 is a flow chart of an exemplary method for facilitating oiUine 
payment transactions through multiple pa)nnent instruments using risk analysis; 

Figures 10 - 19 are exemplary representations of various interfaces included 
in the sequence of interfaces shown in Figure 8; and 

Figure 20 is a block diagram of one embodiment of a computer system. 
DETAILED DESCRIPTION 

A method and apparatus for facilitating online payment transactions in a 
network-based transaction facility using various payment instruments are described- 
In the following description, for purposes of explanation, numerous specific details 
are set forth in order to provide a thorough understanding of the present invention. 
It will be evident, however, to one skilled in the art that the present invention may 
be practiced without these specific details. 

System for Processing Online Payment Transactions 

Figure 1 is a block diagram of one embodiment of a system for processing 

online payment transactions between participants in a network-based transaction 

facility. In this embodiment, a client 100 is coupled to a transaction facility 130 via a 

coxnmimications network, including a wide area network 110 such as, for example, 

the Internet. Other examples of networks that the client may utilize to access the 

transaction facility 130 include a local area network (LAN), a wireless network (e.g., 

a cellular network), or the Plain Old Telephone Service (POTS) network. 

The client 100 represents a device that allows a user to participate in a 
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transaction facility 130. The transaction facility 130 handles all transactions between 
various participants including the user of the client computer 100. In one 
embodiment, the transaction facility 130 may be an online auction facility 
represented by an auction web site visited by various participants including the user 
of the client computer 100. An exemplary auction facility is described in greater 
detail in conjimction with Figure 2. Alternatively, the transaction facility 130 may be 
an or\line retailer or wholesaler facility represented by a retailer or wholesaler web 
site visited by various buyers including the user of the client computer 100. In yet 
other embodiments, the transactions facility 130 may be any other online 
envirorunent used by a participant to conduct business transactions. 

The transaction facility 130 is coupled to an online payment service 120. In 
one embodiment, the transaction facility 130 is coupled to the online payment 
service 120 via a commimications network such as, for example, an internal network, 
the wide area network 110, a wireless network (e.g., a cellular network), or the Plain 
Old Telephone Service (POTS) network. Alternatively, the online payment service 
120 is integrated with the transaction facility 130 and it is a part of the transaction 
facility 130. The online payment service 120 is also coupled to the client 100 via any 
of the described above conununications networks. The online payment service 120 is 
a service for enabling online payment transactions between participants of the 
transaction facility 130, including the user of the client computer 100. 

In one embodiment, the online payments service 120 enables the participants 

to make online payments in the course of business conducted in the transaction 

facility 130 using multiple payment instructions. These payment instructior\s may 

include, for example, credit cards, debit cards, wire transfers, electronic funds 

transfers (EFT), transfers from internal accounts within the transaction facility 130 or 

the online payment service 120, loan financing, lines of credit, coupon or gift 

certificates, etc. In this embodiment, the transaction facility 130 facilitates business 

transaction between the user of the client 110 and other participants. The client tllO 

presents user interface information to the user. The user interface information 

identifies multiple payment instnoments available for processing payment 

transactions pertaining to corresponding business transactions. 
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In one embodiment, the user selects one or more payments instruments from 
the available payments instruments. The client 110 then communicates payment 
option information of the user to the transaction facility 130. The payment option 
information indicates the willingness of the user to accept pa5rments from other 
participants via the selected payment instruments. The online pa)rment service 120 
receives the payment option information from the transaction facility 130, 
communicates the payment option information to a participant conducting business 
with the user, and enables the participant to choose a preferred instriunent from the 
payment instruments selected by the user. The online payment service 120 then 
accepts personal billing information concerning the preferred payment instrument 
from the participant to facilitate the payment transaction between the participant 
and the user. 

Transaction Facility 

Figure 2 is a block diagram illustrating an exemplary network-based 
transaction facility in the form of an Internet-based auction facility 200. While an 
exemplary embodiment of the present invention is described within the context of an 
auction facility, it will be appreciated by those skilled in the art that the invention 
will find application in many different types of computer-based, and network-based, 
commerce facilities. 

The auction facility 200 includes one or more of a number of types of front- 
end servers, namely page servers 212 that deliver web pages (e.g., markup language 
documents), picture servers 214 that dynamically deliver images to be displayed 
within Web pages, listing servers 216, CGI servers 218 that provide an intelligent 
interface to the back-end of facility 210, and search servers 220 that handle search 
requests to the facility 10. E-mail servers 221 provide, inter alia, automated e-mail 
communications to users of the facility 200. 

The back-end servers include a database engine server 222, a search index 
server 224 and a credit card database server 226, each of which maintains and 
facilitates access to a respective database. 

The Internet-based auction f acihty 200 may be accessed by a client program, 

such as a browser (e.g., the Internet Explorer distributed by Microsoft Corp. of 
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Redmond, Washington) that executes on the client computer 100 and accesses the 
facility 200 via the communications network 110. 

Online Payment Service 

Figure 3 is a block diagram of one embodiment of an online payment service 
120. The online payment service 120 includes a firewall 300, one or more web 
servers 310, a firewall 315, a set of application servers 320, and one or more 
databases 330. The firewall 300 isolates the oriline payment service 120 from external 
Internet accesses. The firewall 310 enhances security within the online payment 
service 120 by preventing internal access to information stored in the database 330. 
The orUy access permitted to the database is from applications servers 320, making 
valid database requests. 

The web servers 310 facilitate the exchange of information between the online 
payment service 120, the transaction facility 130 and the participants of the 
transaction facility 130, including the user of the client 100. In one embodiment, the 
web servers 310 encrypt data outgoing from the online payment service 120 using a 
secure protocol (e.g., a secure socket layer (SSL) protocol, a secure HTTP protocol, 
etc.). In one embodiment, a digital signature mechanism is implemented to prevent 
tampering of data prior to the encryption stage. 

The application servers 320 handle various tasks executed within the online 
payment service 120. Each application server 320 is responsible for a certain pre- 
assigned task. These tasks may include, for example, executing payment 
transactions, registering participant accovmts, maintaining account statuses for each 
user, providing customer service, delivering emails, providing analysis (e.g., risk 
analysis) and reporting, processing electroruc fund transfers EFTs, and other 
application services. The applications servers 320 access the database 330 to enter or 
retrieve various data. The database 330 is described in greater detail below in 
conjimction with Figure 6. 

In one embodiment, the online payment service 120 is coupled, via a network, 

to multiple external payment processors to complete various types of online 

payment transactions. For example, the online payment service 120 may be coupled 

to a credit card processor to process credit card pa)ncnents. The online payment 
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service is 120 may also by coupled to an EFT processor to process electromc checks 
and money order payments. Other external payment processor may include, for 
example, a wire transfer processor, a loan financing processor, a line of aedit 
processor, a coupon or gift certificate processor, etc. 

Figure 6 is a database diagram illustrating an exemplary database 600 
supported by the online payment service 120. The database 600 may, in one 
embodiment, be implemented as a relational database, and includes a number of 
tables having entries, or records, that are linked by indices and keys. In an 
alternative embodiment, the database 600 may be implemented as collection of 
objects in an object-oriented database. 

Central to the database 600 is a user table 610, which contains a record for 
each user of the online payment service 120. A user may operate as a seller, buyer, 
or both, within the transaction facility 130. A seller table 620 is linked to the user 
table 610 and includes more detailed information about each seller. A buyer table 
630 which is also linked to the user table 410 includes detailed information about 
each buyer. The database 600 also includes payment instruments tables 670 that 
may be linked to the user table 610. Each payment instrument table 670 pertains to 
an individual payment instrument available for use in the transaction facility 130. 
Available payment instruments may include, for example, credit cards, debit cards, 
automated clearing house (ACH) transfers using electronic checks and money 
orders, wire transfers, transfers from an internal account within the online payment 
service 120 or the transaction facility 130, loan financing, lines of credit, coupons or 
gift certificates, etc. Each payment instrument table 670 includes corresponding 
billing information provided by a user. A user record in the user table 610 may be 
linked to a payment instrument record in multiple payment instrtunent tables 670 if 
the user provides billing information on more than one payment instrument. 

The database 600 also includes a payment transaction table 640 which is 

linked to the seller table 620 and the buyer table 630. The payment transaction table 

640 contains information on each financial exchange between a buyer and a seller. A 

payment transaction in the transaction table 640 may be represented by one or more 

accoimting records in an accoimting record table 650. The accounting records 
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support an accounting system of the online payment service 120 and contain various 
accounting information, such as, for example, information on debits and credits to 
buyers, sellers, the online payment service, or other third parties participating in 
pajmient transaction. A payment transaction that does not corresponds to any 
accoimting record may indicate that the transaction was not completed successfully 
(e.g., the buyer's credit card v/as invalid). 

A ledger table 660 is linked to the accoimting record table 650, the user table 
610 and the payment instrument tables 670. A ledger record contains information on 
an actual fund transfer between a user and the online payment service 120. The 
funds transfer may be a debit (e.g., a charge to a buyer's credit card) or a credit (e.g., 
a disbursement to a seller's checking account). The funds transfer is conducted 
through a particular payment instrument selected by the buyer and seller and 
approved by the online payment service 120 in a maimer described in more detail 
below. 

One embodiment of an architecture of the online payment servicel20 will 

now be described in more detail. In this embodiment, the online payment service 

120 supports a large number of buyers and sellers who are distributed across the 

globe, executing transactions at any time of day and night. In order to provide stable 

physical environment and reUable application architecture, online payment service 

dusters are installed at several different geographical locations. If a single data 

center location goes dovm, transaction volimae can be processed by dusters at the 

remaining locations. Each duster, in turn, may consist of multiple machines with 

redundant service. 

Figure 4 is a block diagram of an exemplary online payment service 120 

supporting multiple data centers. In this embodiment, dusters 400, 410 and 420 

reside in different data centers. The same web servers 310 and application servers 

320 are induded in both clusters 400 and 410. The application servers 320 of the 

dusters 400 and 410 perform transaction management functions, such as, for 

example, transaction execution, account registration, account status, customer 

service, e-mail delivery, etc. In one embodiment, in each of the dusters 400 and 

410, multiple instances of every application server nm in parallel to balance the 
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system load between the different functions. Application servers can be installed 
on different physical machines to increase reliability of the system. In one 
embodiment, each of the diisters 400 and 410 has external connections with one or 
more payment processors (e.g., a credit card processor, an EFT processor, a wire 
transfer processor, etc). 

In one embodiment, each of the dusters 400 and 410 indudes a production 
database 330. Shared data (e.g., buyer and seller profile information) in the 
production database 330 may be dynamically replicated to both data centers. 
Transaction data (e.g., current accoxmt statement information) may not need to be 
replicated as it can be constructed in a variety of other ways using the production 
data. For example, upon a user request for an online accovmt statement, a query 
(e.g., an SQL query) may be run to build a complete transaction record. 

In one embodiment, analysis and reporting functions may be separated from 
the transaction activity because these functions are time consuming. That is, analysis 
and reporting functions may be executed by the warehouse duster 420 located 
separately from the dusters 400 and 410. The analysis and reporting functions may 
indude, for example, risk or fraud analysis, standard reporting, online analytical 
processing (OLAP) providing database indexing to enhance quick access to data 
EFT processing, etc. The analysis and reporting fvmctions may be carried out 
against a separate data warehouse system, such as a data warehouse 450. Data 
pertaiiung to the analysis and reporting may be extracted from the production 
database 330 at predefined time intervals and stored in the data warehouse 450. As 
a result, user transaction activity is not impacted by execution of time-consuming 
analysis and reporting functions. 

Multiple Payment Instruments 

In order to provide partidpants of the transaction facility 130 with an 

effective and secure mechanism of conducting online payment transactions, one 

embodiment of the present invention proposes a method and system whereby the 

participants may conveniently use multiple payment instruments to make online 

payments for products obtained in the coxarse of their commercial activity m the 
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transaction facility 130. 

Figxire 5 is a flow chart illustrating an exemplary method 500 of facilitating 
online pa5nnent transactions using multiple payment instruments. The method 500 
may be performed by processing logic, which may comprise hardware, software, or 
a combination of both. The processing logic may be either in the online payment 
service 120, or partially or entirely in a separate device and/or system(s). 

Referring to Figure 5, the method 500 begins with the online payment 
service 120 conmirmicating user interface information to a first participant via a 
communications network (processing block 506). The user interface information 
identifies multiple payment instruments available for processing payment 
transactions in the transaction facility 130. 

At processing block 508, processing logic in the online payment service 120 
receives payment option information from the first participant via the 
communications network. The payment option information indicates a 
willingness of the first participant to accept payments from a second participant 
through one or more available payment instruments. As described above, 
available payment instruments may include, for example, credit cards, debit cards, 
wire transfers, electronic checks and money orders. In addition, the online 
payment service 120 may permit payments through direct transfers from an 
internal accoimt which is maintained for a participant within the transaction 
facility 130 or the ordine payment service 120. 

In one embodiment, payment instruments may also include loan financing 
and Lines of credit. In this embodiment, the online payment service 120 may 
cooperate with a third party processor (e.g., a financial institution) to process loan 
financing and to create or extend a line of credit for a participant. Other payment 
instriraients may include coupons and gift certificates, or any other U.S. or 
international vehicles. In the cases of coupons and gift certificates, the ordine 
payment service 120 (in cooperation with a third party or internally) determines 
whether a coupon or a gift certificate is vaUd. 

Next, processing logic in the online payment service 120 passes the payment 

option information to the second participant via the commimications network 
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(processing block 510). Afterwards, at processing block 512, processing logic in 
the orJine payment service accepts personal billing iiiformation of the second 
participant to facilitate a payment transaction between the first participant and the 
second participant. The personal billing information transferred over the 
commimications network pertains to a payment instrument selected by the second 
participant from the payment instnxments specified by the first participant. 

In one embodiment, processing logic in the ortline payment system 120 
communicates the personal billing information of the second participant, via the 
communications network, to a fiaandal ir\stitution to process the payment 
transaction. Alternatively, the personal billing information may be processed 
internally (e.g., when a payment is made using a direct transfer from an intemal 
accoimt within the online payment system 120 or the transaction facility 130). 
Afterwards, when the payment transaction completes, the first participant is 
notified. In one embodiment, notification may be sent immediately after accepting 
the personal billing information (e.g., when a pa)nTient is made using a credit card). 
Alternatively, notification is sent after a certain time period expires (e.g., when a 
payment is made using an electronic check). 

In one embodiment, at various stages of the payment transaction between 
the first participant and the second participant, risk involved in the payment 
transactions is evaluated by a risk analysis system of the online payment system 
120. The various stages may include, for example, the time the payment 
transaction is initiated, the time either the first or second participant registers with 
the online payment service 120, the time the first participant provides invoice 
information, the time the second participant provides personal billing information 
pertaining to a particular payment instrtiment, the time funds are disbursed to the 
first participant, etc. Based on the involved risk, the payment transaction between 
the first and second participants may be interrupted or restricted (e.g., preventing 
a participant from accepting or paying with a certain payment instrument). The 
risk analysis system is described in greater detail below in conjunction with Figure 
7. 

In one embodiment, processing logic in the online payment service 120 
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accepts multiple payments owed to the fixst participants by other participants in the 
course of business transactions conducted by the first participant in the transaction 
facility 130. The multiple payments are accepted via the commtmications network 
and may be made using various payment instruments. Next, processing logic in the 
online payment service 120 accumulates these payments over a period of time and 
then distributes a single disbursement which includes the accumulated payments to 
the first participant. 

In one embodiment, the online payment service 120 accepts a payment from 
the second participant in one currency and distributes the payment to the first 
participant in different currency. The above online payment options address time- 
consuming and imreliable paper-based payment methods and provide an efficient 
and secure mechanism to conduct payment transactions within the transaction 
facility 130. 

Figure 7 is a block diagram of one embodiment of a process flow for 
evaluating risks involved in an online payment transaction. As described above, the 
involved risks are evaluated at various stages of the payment transaction. The 
involved risks may concern, for example, a buyer's ability to pay, a Hkelihood that a 
buyer or a seller may be fraudulent (e.g., a buyer uses a stolen credit card, or a seller 
lists goods for sale online with no intent or ability to deliver the purchased goods), a 
seller's ability to fulfill purchase orders promptly, etc. Based on the risk evaluation, 
the online payment service 120 may reject or restrict a payment transaction between 
a buyer and a seller in a manner described below. In one embodiment, the risk 
evaluation is performed in real time and enables an uninterrupted processing of the 
payment transaction. 

In one embodiment, the online payment service 120 contains a payment 

processing system 710 and a risk management system 720. The payment processing 

system 710 is responsible for executing payment transactions. SpedLficaUy, the 

payment processing system 710 receives information from the transaction facility, 

stores some or all of this information for historical purposes in a local database (i.e., a 

pajnnent transaction data store 730), and determines what information to pass to the 

risk management system 720. The risk management system 720 utilizes this 
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information to deteraune a risk level involved in the payment transaction. In one 
embodiment, the risk management system 720 may also use input from one or more 
third party risk analysis providers 740 to evaluate the risk level of the payment 
transaction. The resxilts of the evaluation are passed back to the payment processing 
system 710 which continues processing the payment transaction based on the 
evaluation resiilts. 

In one embodiment, payment transactions are initiated in the transaction 
facility 130. The transaction facility 130 passes a variety of information concerning a 
payment transaction and its participants (a buyer and a seller) to the payment 
processing system 710. The payment transaction information may include, for 
example, a payment transaction amount, currency in which the payment transaction 
is to be conducted, description of the goods or services being exchanged, etc. The 
participant information may include, for example, identifying information of both a 
buyer and a seller (e.g., names, identification codes, contact information) and 
information pertaining to their business participation in the transaction facility 130. 
For instance, the transaction facility 130 may pass to the payment processing system 
710 information on how long both the buyer and the seller have been registered with 
the transaction facility 130, their historical business activity within the transaction 
fadlity 130 (e.g., number of prior transactions, gross sales, average amoimt of a sale), 
user classification schemes and peer rating schemes used in the transaction facility 
130 (e.g. user feedback ratings), third party trust ratings carried out by the 
transaction facility 130 (e.g. credit reports), etc. It should be noted that a wide 
variety of information other than the information described above may be passed to 
the pajnnent processing system 710 from the transaction facility 130 for evaluating 
potential risk involved in the payment transaction. 

In another embodiment, the payment processing system 710 itself may initiate 

a payment transaction (e.g., if the payment processing system 710 is notified that a 

buyer and a seller agreed that a payment would take place on a future date). In this 

embodiment, the payment processing system 710 then requests relevant information 

(including any or edl of the above information) from the transaction facility 130. 

The payment processing system 710 passes any or all of the above 
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information to the risk management system 720. In addition, the payment 
processing system 710 may pass certain internal transaction data (e.g., response 
codes from a credit card processor) to the risk management system 720. The risk 
management system 720 tises the above information to determine the risk level of 
the payment transaction. In addition, the risk management system 720 may include 
in its analysis data stored in the pa5ni\ent trai\saction data store 730 (e.g. historical 
transaction activity of the seller and the buyer) and information collected by system 
operation staff related to either the buyer or the seller (e.g., customer service 
responses, ''blacklists" identifying fraudulent customers, etc.). 

In one embodiment, the risk management system 720 also includes in its 
analysis external risk analysis results. In this embodiment, the risk management 
system 720 may request one or more third party risk analysis providers 740 to 
provide an additional evaluation of the risk involved in the payment transaction. 
For instance, a financial institution may provide additional levels of screening to 
identify potentially fraudulent participants. The risk management system 720 may 
transmit to the third party risk analysis providers 740 any or all of the information 
collected for the payment transaction. The third party risk analysis providers 740 
analyzes this information and information obtained from their own sources to 
determine a risk assessment for the payment transaction. The risk assessment 
information is then sent back to the risk management system 720. 

Based on the information received from various external and internal soxirces, 

the risk management system 720 determines the risk level of the payment 

transaction using a scoring algorithm. It should be noted that any scoring algorithm 

known in the art may be used by the risk management system 720 without loss of 

generality. The risk management system 720 produces a consolidated risk response 

and passes it to the payment processing system 710. The risk response may include, 

for example, information indicating that service should be denied to a participant 

due to high likelihood of fraud, information on a recommended service fee for 

processing the payment transaction, information on recommended restrictions on 

payment instruments to be used by either the buyer or the seller, information on 

reconrunended restrictions on disbursing funds to the seller, etc. 
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The payment processing system 710 receives the risk response from the risk 
management system 720 and makes a final determination concerning the payment 
transaction. That is, the payment processing system 710 may reject the payment 
transaction (or deny service to either the buyer or the seller entirely), process the 
payment transaction without any changes, or restrict the timing and /or the manner 
in which the payment transaction is conducted. For example, the payment 
processing system 710 may limit payment instruments offered for use in the 
payment transaction, may assign or modify a fee for processing the payment 
transaction, may restrict the time or the maimer in which funds are disbursed to the 
seller, etc. 

User Interfaces 

Fimctions of the online payment service 120 pertaining to payments through 
multiple payment instruments will now be described within the context of user 
interfaces, according to one embodiment of the present invention. Figure 8 shows an 
interface sequence 800, according to an exemplary embodiment of the present 
invention, that may be implemented by the transaction facility 130 and the online 
payment service 120 for the purposes of providing multiple online payment options 
to participants in the transaction facility 130. Exemplary representations of the 
various interfaces included within the sequence 800 are shown in Figures 10-19. 
While exemplary interfaces are described within the context of an auction facility, it 
will be appreciated by those skilled in the art that they may be implemented in many 
different types of computer-based, and network-based, transaction facilities. 

The interface sequence 800 commences with a seller registration interface 802 
through which a seller may specify what online payment instruments the seller will 
accept from various buyers. The seller registration interface 802 is generated by the 
transaction facility 130 and may be accessed at any time during a business 
transaction (e.g., during an auction) or upon an end of the business transaction (e.g., 
upon en and of auction). The seller needs to go through the seller registration 
interface 802 only once unless the seller wants to modify the payment instruments 
specified initially. 
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Upon the end of the business transaction, an end of bxisiness transaction 
interface 804 is displayed by the transaction facility 130. The end of business 
transaction interface 804 identifies a seller and a buyer and the payment instruments 
acceptable to the seller. If the payment transaction is initiated by the seller, the seller 
is then presented with a seller login interface 806 which allows the seller to login to 
the online payment service 120 by entering the seller's password. Subsequently, the 
seller is presented with an invoice form interface 808. The invoice form interface 808 
displays an explanation of the payment process and requests the seller to enter the 
invoice terms. 

After the seller corifirms that the invoice terms are correct, the buyer receives 
an email with a link to a buyer login interface 810. Alternatively, if the payment 
transaction is irutiated by the buyer, the invoice is not generated and the buyer does 
not need to wait for the above email. Instead the buyer can directly access the buyer 
login interface 810 which enables the buyer to login to the online payment service 
120. 

Next, the buyer is presented with a payment option interface 812 which 
allows the buyer to select a particular payment instnmient for use in this payment 
transaction. In addition, the payment option interface 812 enables the buyer to avoid 
entering the buyer's personal billing information in a personal billing information 
interface 814 if the buyer has previously registered with the online pajmient service 
120. If so, the buyer is presented with a revision of billing and shipping information 
interface 813 and then with an order placing interface 818. By clicking a place order 
button on the order placing interface 818, the buyer authorizes the online payment 
service to execute the payment transaction (e.g., charging the buyer's credit card, 
initiating an electroruc funds transfer, etc.). Further, the buyer is presented with a 
confirmation interface 820 confirming that the buyer's purchase is complete. In case 
of an electronic funds transfer, the confirmation interface 820 notifies the buyer that 
the online payment service 120 has iiutiated the buyer's electronic check payment. 

If the buyer has not previously registered with the ordine payment service 
120, the buyer is presented with the personal billing information interface 814 which 

requests the buyer to enter biUing information pertaining to the payment instrument 
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selected by the buyer. Next, the buyer is presented with a shipping information 
interface 816 which requests the buyer to enter shipping information for this order 
and then with an order placing interface 818 and then with the confirmation 
interface 820. Afterwards, the buyer is invited to register with the online payment 
service 120 using a buyer registration interface 822. By registering, the buyer 
permits the online payment service 120 to store the buyer's personal billing 
information so that the buyer does not need to enter it every time the buyer pays for 
the goods through a corresponding payment instrument. The personal billing 
information of the buyer is kept confidential and is not commimicated to the seller. 

The interfaces 802-820 will now be described within the context of a method 
900, according to one embodiment of the present invention, of facilitating payment 
transactions through miiltiple payment instruments using risk analysis. The method 
900 is illustrated by the flow chart indicated in Figure 9. The method 900 is 
performed by processing logic, which may comprise hardware, software, or a 
combination of both. The processing logic may be either in the online payment 
service 120, or partially or entirely in a separate device and /or system(s). 

The method 900 commences with providing the seller registration interface 
802 to the seller at block 904. The seller registration interface presents to the seller 
available payment instrxmients that can be used for conducting pa5anent 
transactions in the transaction facility 130. 

At block 906, processing logic in the online payment service 120 receives 
information on payment instruments selected by the seller from the list of available 
payment instrxrments. At block 908, processing logic in the online payment option 
120 determines whether the seller is qualified to use the payment instruments 
selected by the seller. This determination is performed using the risk management 
system 720 as described above in conjunction with Figiure 7. 

The method 900 continues with providing the end of business transaction 
interface 804 which specifies those payment instruments selected by the seller that 
were approved during the risk analysis process (block 910). Next, at decision box 
912, a determination is made as to whether an initiator of the payment transaction is 
the seller or the buyer. If the seller initiates the payment transaction, the seller is 
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provided with the seller login interface 806 to enable the seller to login to the online 
payment service (block 914). At block 916, the seller is presented with the invoice 
form interface 916. 

Next, at block 918, processing logic in the online payment service 120 receives 
invoice information entered by the seller through the invoice form interface 808 and 
then, at block 920, determines whether the seller is qualified to submit the payment 
transaction described by the invoice information. That is, the risk management 
system 720 is used to evaluate a likelihood of the seller's ability to fulfill the 
purchase according to the invoice terms. If processing logic in the online payment 
service 120 determines that the seller is qualified to submit this payment transaction, 
the buyer is sent an e-mail which contains a link to begin payment. The link enables 
the buyer to access the buyer login interface 810 (block 922). 

Alternatively, if the initiator of the payment transaction is the buyer, the 
method 900 proceeds directly to block 922, at which the buyer is presented with the 
buyer login interface 810. The buyer login interface 810 includes information 
instructing the buyer to notify the seller (e.g., by e-mail using included e-mail 
template) about the buyer's willingness to conduct the payment transaction through 
one of the available payment instrimnents. 

Further, after the buyer successfully logs in to the online payment service 120, 
at decision box 924, a determination is made as to whether the buyer is registered 
with the online payment service 120. If the buyer is not registered, the buyer is 
requested to specify a preferred payment method for this payment transaction 
through the payment option interface 810. If the buyer initiated the payment 
transaction, the preferred payment method may be selected from multiple payment 
instnmients available for conducting payment transactions in the transaction facility 
130. Alternatively, if the irdtiator of the payment transaction was the seller, the 
preferred pa5rment method may be selected from the payment instruments approved 
in the qualification process described above. 

At decision box 928, a determination is made as whether the buyer is qualified 

to use the preferred payment instrument using the risk evaluation process described 

above. If the buyer is not qualified to use this payment instrument, the method 900 
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returns to block 926, at which the buyer is asked to select another payment 
instrximent. Alternatively, if the buyer is qualified, at block 930, the buyer's personal 
billing information pertaining to the preferred billing instrument is received from 
the buyer through the personal billing information interface 814. Information 
included in the personal billing information interface 814 varies depending on the 
payment instrument selected by the buyer. In addition, the buyer may be requested 
to enter the buyer's shipping information through the shipping iiiformation interface 
816. 

Next, at block 934, processing logic in the online pa5mient service 120 
processes the buyer's payment and generates the confirmation interface 820 
notifying the buyer either that the purchase is complete (e.g., the payment is made 
through a credit card) or that the buyer's payment has been iiutiated (e.g., the 
payment is made through an electronic funds transfer). Further, the buyer is 
presented with the buyer registration interface 822 which enables the buyer to store 
the buyer's personal bilUng information and shipping information in an accoimt 
maintained for the buyer by the online payment service 120. The method 900 then 
proceeds to block 936. 

In an alternate embodiment, in which the buyer is already registered with the 
online pa)ninent service 120, the method 900 proceeds to block 927, at which the 
buyer is invited to revise his or her billing and /or shipping information through the 
revision of billing and shipping information interface 813. Then, the method 900 
proceeds to block 934 and further to block 934. 

At block 934, processing logic in the online payment service 120 disburses 

funds to the seller. In one embodiment, multiple payments made by various buyers 

using the same or different payment instruments are accxmnulated on behalf of the 

seller over a certain period of time and then a single disbursement (in the amovint 

equal to the accumulated payments minus an appropriate service fee) is distributed 

to the seller. In one embodiment, the time of disbursement, the maimer of 

disbursement (e.g., a payment instrximent to be used for disbursement) and the 

amoimt of the service fee are determined based on the risk evaluation process 

described above in conjunction with Figure 7. 
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Exemplary user interfaces will now be further described with reference to 
Figures 10-19. While the exemplary interfaces are described as comprising markup 
language documents displayed by a browser, it will be appreciated that the 
described interfaces could comprise user interfaces presented by any Windows® 
client application or stand-alone application, and need not necessarily comprise 
markup language documents. In addition, it will be appreciated by those skilled in 
the art that, although the exemplary interfaces are described in the context of an 
auction facility, they may be implemented in a wide variety of different types of 
computer-based, and network-based, transaction facilities. 

Figure 10 illustrates an exemplary seller registration interface 802 that enables 
the seller to specify various options concerning business transactions that are 
conducted in the envirorm\ent of the transaction facility 130. Some of the various 
options pertain to payment options, such as payment methods 1010 and online 
payments 1020. The online payments 1020 specify multiple payment instrimients. 
Although Figure 10 illustrates only credit card and electronic check pa)mient 
ir\struments, the seller registration interface may identify a wide variety of other 
payment instruments as described above. Using one or more check boxes 
corresponding to the payment instrviments (e.g. check box 1022 and 1024), the seller 
may specify what payment instruments he or she will accept in payment 
transactions with various buyers. 

Figvire 11 illustrates an exemplary end of business transaction interface 804 
which in this example indicates the end of auction. The end of business transaction 
interface specifies payment instruments selected by the seller (e.g. a credit card 1110 
and an electronic check 1120) and enables either the seller or the buyer to initiate the 
pajnnent transaction by using a corresponding link (i.e., a seller link 1124 or a buyer 
link 1124). 

Figure 12 is an exemplary seller login interface 806 which enables the seller to 

login to the online payment service 120 by providing the seller's password 1230. The 

seller login interface 806 also includes links to explanations on how to use online 

payments (e.g., a link 1210 to an explanation for a first step of sending an invoice and 

a link 1220 to an explanation for a second step of shipping an item). 
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Figxire 13 is an exemplary invoice form interface 808 which includes input 
fields for entering various invoice information (e.g., a final auction price 1330, 
shipping insurance 1340, sales tax 1350, a message 1386, and a return policy 1388). 
The invoice interface also specifies payment instnnnents 1380 that are acceptable for 
this transaction (e.g., credit card 1382 and electronic check 1384) and provides 
information on how the payment transaction wiU be processed. For example, if the 
buyer chooses to pay with a credit card, the seller will be notified that the payment is 
processed once the buyer's credit card information is received. If the buyer pays 
with an electronic check, the seller will be notified about the completion of the 
payment transaction after the expiration of a certain time period (e.g. in 3-5 days). 

Figure 14 is an exemplary buyer login interface 810 which enables the buyer 
to login to the online pa)nnent service 120 by providing the buyer's user identifier 
1414 and password 1416. In addition, the buyer login interface 810 includes 
information indicating that the payment transaction must be either initiated by the 
seller 230 (text 1410) or the buyer (text 1412). 

Figure 15 is an exemplary payment option interface 812 which includes 
invoice information 1510 and asks the buyer to select one of the online payment 
methods (e.g., a credit card 1530 or an electronic check 1540) by using either a ''pay 
with credit card" button 1550 or a "pay with electronic check" button 1560. The 
payment option interface also allows the buyer to pay in one step using a link 1520 if 
the buyer is registered with the online payment service 120. 

Figxure 16 is an exemplary biUing information interface 814 generated in 
response to a buyer request to pay with a credit card payment instrument. The 
interface 814 includes input fields 1620 pertaining to the buyer's credit card 
information. In addition, the interface 814 includes information indicating that the 
buyer's billing information is kept confidential and will not be disclosed to the seller. 

Figure 17 is an exemplary billing information interface 814 generated in 

response to a buyer request to pay with an electronic check payment instrument. 

The interface 814 includes the buyer's checking accotmt information including a 

bank name 1710, a bank routing number 1720, a checking account 1730, and a 

buyer's name and a checking accoxint address 1750. In one embodiment, in order to 
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prevent potential fraudiolent activity, the interface 814 includes secondary form of 

identification input fields 1762-1768. 

Figure 18 is an exemplary buyer registration interface 822 including input 

fields 1810-1850 enabling the buyer to register with the online payment service 120 

for storing his or her billing information in an account maintained by the online 

payment service 120. 

Figure 19 is an exemplary confirmation interface 820 notifying the user that 

the payment transaction has been initiated. 

In stimmary, it will be appreciated that the above described interfaces, and 

underlying technologies, provide a convenient vehicle for facilitating payment 

transactions in a transaction facility vising multiple payment instruments. 

Figure 20 shows a diagrammatic representation of machine in the exemplary 
form of a computer system 2000 within which a set of instructions, for causing the 
machine to perform any one of the methodologies discussed above, may be 
executed. In alternative embodiments, the machine may comprise a network 
router, a network switch, a network bridge. Personal Digital Assistant (PDA), a 
cellular telephone, a web appliance or any machine capable of executing a sequence 
of instructions that specify actions to be taken by that machine. 

The computer system 2000 includes a processor 2002, a main memory 2004 
and a static memory 2006, which commurucate with each other via a bus 2008. The 
computer system 2000 may further include a video display imit 2010 (e.g., a liquid 
crystal display (LCD) or a cathode ray tube (CRT)). The computer system 2000 also 
includes an alpha-numeric input device 2012 (e.g., a keyboard), a cursor control 
device 2014 (e.g.,a mouse), a disk drive unit 2016, a signal generation device 2020 
(e.g., a speaker) and a network interface device 2022. 

The disk drive unit 2016 includes a computer-readable medium 2024 on 
which is stored a set of instructioris (i.e., software) 2026 embodying any one, or all, 
of the methodologies described above. The software 2026 is also shown to reside, 
completely or at least partially, within the main memory 2004 and/or within the 
processor 2002. The software 2026 may further be transmitted or received via the 
network interface device 2022. For the purposes of this specification, the term " 
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computer-readable medium" shall be taken to include any mediiun that is capable 
of storing or encoding a sequence oiF instructions for execution by the computer and 
that cause the computer to perform any one of the methodologies of the present 
invention. The term "computer-readable medium" shall accordingly be taken to 
included, but not be limited to, solid-state memories, optical and magnetic disks, 
and carrier wave signals. 

Thus, a method and apparatus for facilitating online payment transactions in 
a network-based transaction facility using multiple payment instruments have been 
described. Although the present invention has been described with reference to 
specific exemplary embodiments, it will be evident that various modifications and 
changes may be made to these embodiments without departing from the broader 
spirit and scope of the invention. Accordingly, the specification and drawings are to 
be regarded in an illustrative rather than a restrictive ser\se. 
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CLAIMS 

What is claimed is: 

1. A method for facilitating online payment transactions between participants in 
a network-based transaction facility, the method comprising: 

commtmicating user interface information to a first participant via a 
commimications network, the user interface information identifjdng a plurality of 
pajnnent instruments available for processing online payment transactions in the 
network-based transaction facility; 

receiving payment option information from the first participant via the 
coixunimications network, the payment option information indicating a willingness 
of the first participant to accept pajmnents from a second participant via at least one 
of the plurality of payment instruments; 

passing the payment option information to the second participant via the 
commimications network; and 

accepting personal billing information concerning a payment instrument 
selected by the second participant from the at least one of the pluratity of payment 
instruments, the personal billing iriformation being accepted via the communications 
network to facilitate an online payment transaction between the first participant and 
the second participant. 

2. The method of claim 1 further comprising: 

dynamically evaluating risk involved in the online payment transaction 
between the first participant and the second participant; and restricting the online 
payment transaction based on the evaluated risk. 

3. The method of claim 2 wherein the involved risk is evaluated using various 
information concerning the first participant and the second participant, the various 
irif ormation including information stored by an online payment service and 
information obtained from any one of a pluraHty of third party risk analysis 
providers via the communications network. 
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4. The method of claim 2 wherein the involved risk is evaluated at varioxis 
stages of the online payment transaction between the first participant and the second 
participant. 

5. The method of claim 1 further comprising: 

accepting multiple pa)nnents issued to the first participant in a course of 
business traiisactions conducted by the first participant; 

accumulating the multiple payments over a period of time as a single 
accumulated payment; and 

disbursing the single accxmiulated payment to the first participant. 

6. The method of daim 5 wherein the multiple payments are accepted over the 
commimications network using the plurality of payment instruments. 

7. The method of daim 1 wherein the network-based transaction fadlity 
comprises a network-based auction fadlity. 

8. The method of daim 1 further comprising: 

communicating the personal billing information of the second partidpant to a 
finandal institution to process the online payment transaction, the personal billing 
information being commimicated over the commvmications network; and 

notifying the first partidpant when the online payment transaction completes. 

9. The method of daim 1 further comprising: 

enabling the first partidpant to initiate the online payment transaction via 
commimications network; 

communicating to the first partidpant an invoice form interface to obtain 
invoice information from the first partidpant; 

determining that the first participant is qualified to initiate the online 

payment transaction described by terms induded in the invoice information; and 
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passing the invoice information to the second participant. 

10. The method of claim 1 further comprising: 

enabling the second participant to initiate the online payment transaction via 
communications network; 

communicating to the first participant information indicating a willingness of 
the second participant to use one of the plurality of payment instruments; 

determining that the second participant is qualified to use the one of the 
plurality of payment instruments; and 

providing a billing information interface to the second participant to obtain 
personal billing information concerning the one of the plurality of payment 
instruments. 

11. The method of claim 1 wherein the personal billing information is encrypted. 

12. The method of claim 1 wherein the personal billing information of the second 
participant is not disclosed to the first participant unless permitted by the second 
participant. 

13. A system for facilitating online payment transactions between participants in 
a network-based transaction facility, the system comprising: 

the network-based transaction facility to implement a transaction system that 
facilitates business transactions between a user and a further user; 

a client, coupled to the network-based transaction facility, to present user 

interface information identifying a plurality of payment instruments available for 

processing online payment transactions pertaining to corresponding business 

transactions and to communicate payment option information of the user over a 

commimications network, the payment option information indicating a willingness 

of the user to accept a payment from the further user via at least one of the plurality 

of payment instruments; and 

an online payment service, coupled to the network-based transaction facility 
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and the client via the conraitmications network, to receive the payment option 
information from the client, to make the payment option information available to the 
further user via the communications network, to enable the further user to select a 
preferred payment instrument from the at least one of the payment instruments, and 
to accept personal billing information concerning the preferred payment tnstrimient 
from the further user via the communications network. 

14. The system of daim 13 wherein the online payment service comprises: 

a risk management system to dynamically evaluate risk involved in the online 
pajnnent transaction between the first participant and the second participant; and 

a payment processing system to restrict the online payment transaction based 
on the evaluated risk. 

15. The system of daim 14 wherein the involved risk is evaluated using various 
information concerning the first partidpant and the second partidpant, the various 
information induding information stored by an online payment service and 
information obtained from any one of a plurality of third party risk analysis 
providers via the commtmications network. 

16. The system of claim 14 wherein the involved risk is evaluated at various 
stages of the online payment transaction between the first partidpant and the second 
participant. 

17. The system of claim 13 wherein the online payment service is further 
configured to 

accept multiple payments issued to the first partidpant in a course of 
business transactions conducted by the first partidpant, 

accumulate the multiple payments over a period of time as a single 

accumulated payment, and 

disburse the single accumulated payment to the first partidpant. 
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18. The system of claim 17 wherein the multiple payments are accepted over the 
commimications network using the plurality of payment instruments. 

19. The system of claim 13 wherein the network-based transaction facility 
comprises a network-based auction facility. 

20. The system of claim 13 wherein the online payment service is configured to 

communicate the personal billing iiiformation of tfie second participant 
to a financial institution to process the orUine payment transaction, the 
personal billing information being communicated over the commtmications 
network, and 

notify the first participant when the online payment transaction 
completes. 

21. The system of claim 13 wherein the online payment service is configured to 

enable the first participant to initiate the online payment transaction 
via communications network, 

commimicate to the first participant an invoice form interface to obtain * 
invoice information from the first participant, 

determine that the first participant is qualified to initiate the online 
payment transaction described by terms included in the invoice information, 
and 

pass the invoice information to the second participant. 

22. The system of claim 13 wherein the online payment service is configured to 

enable the second participant to initiate the online payment transaction 
via communications network, 

conmnurucate to the first participant information radicating a 
willingness of the second participant to use one of the plurality of payment 
rnstrximents, 
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determine that the second participant is qualified to use the one of the 
plurality of payment instruments, and 

provide a billing information interface to the second participant to 
obtain personal billing information concerning the one of the plurality of 
payment instruments. 

23. The system of daim 13 wherein the personal billing information is encrypted. 

24. The system of claim 13 wherein the personal billing information of the second 
participant is not disclosed to the first participant imless permitted by the second 
participant. 

25. A computer readable medium comprising instructions, which when executed 
on a processor, cause the processor to perform a method for facilitating online 
payment transactions between participants in a network-based transaction facility, 
the method comprising: 

communicating user interface information to a first participant via a 
commvmications network, the user interface information identifying a plurality of 
pa5rment instruments available for processing online payment transactions in the 
network-based transaction facility; 

receiving pajrment option information from the first participant via the 
communications network, the payment option information indicating a willingness 
of the first participant to accept payments from a second participant via at least one 
of the plurality of payment instruments; 

passing the payment option information to the second participant via the 
communications network; and 

accepting personal billing information concerning a pa)mrient instrument 
selected by the second participant from the at least one of the plurality of payment 
instruments, the personal billing iiiformation being accepted via the cormnimications 
network to facilitate an online payment transaction between the first participant and 
the second participant. 
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820 



Buyer Is Not Registered 



\ Revision of Billing Infomiation 
Interface 

1 — 



Personal Billing Momiation / 
Interface ^ 



Shipping Infonnatiott Interface 



814 



Otder Placing Interface 



Shipping Information Interface y 



Confmnation Interface 



Order Placing Interface 

i 



Confirmation Interface 



Figure 8 



816 



818 



820 



Buyer Registration Interface 



822 
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Start 


902 










Provide seller registration interface to Seller 



904 



Receive online payment options specified by Seller 



Determine whether Seller is qualified to use the specified 
payment option 



Provide an ^-of-auction interface with authorized 
payment options 




Provide a Seller login interface to enable Seller to login 
to the online payment service 



Provide an invoice form interface 



I 



Receive invoice information from Seller 



906 



908 



910 



914 



916 



918 



920 



Determine that Seller is qualified to submit payment 
transaction described bv the invoice infonnation 



Provide a buyer login interface to enable a Buyer to login 
to the online payment service 



Figure 9A 



922 



900 
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raynieni meinuDs 

Choose alt that you will 
accept 


□ Money OrdecfCashieisO)^ 

n COD(C3st>ondefvery) □ COO(Gashond^very) □ American Expfcss 
BSeeftemDesolpfion □ SeeftemDexr^ition □ 


Online payments 

ImcI I 1 
1024 — 


Online Payments iwm mrwa 

Accept credit cards (Visa, MasterCard, and Discover) or electronic checks from 
your winning bidders online. If you are not a registered seller, apply now 

/^1022 

0 Accept Credit Card payments (available to buyers in these CQimtoes) 
-D Accept Electronic Check payments. 


Escrow 


0 1 will accept escrow, buyer pays (recommended) 
Ol wilt pay escrow 

® t wilt not accept escrow, (if selected, the Escrow section wilt not appear on 
the item listing) 

leaauoflie 


Where will you ship? 


® Will ship to United States only 
O Will ship intematlonatty (worldwide) 

O Will ship to United States arKt the following regions: (Check all that apply) 



1010 



FIG. 10 
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Item #330390395 




Currently 
Quantity 
Time left 



flp witgf) 

ftp hkWert 

tfyouantiK 
seOerortfie 
hlQhbUtfer- 
nawwtnrr? 



Jewelry, Gemstones:Beads:Rndings 
Bidding is closed for this item. 

$1.00 

1 

Auction has ended. 



Started May-1 1-00 16:06:38 PDT 
Ends May-11-00 16:07:36 PDT 

Seller (Rating) krattss®tillipQlnt,com(Q) 

(view comments in seller's Feedback Profile) (view seller's other auctions) 

(asK. seller aflUfistlon) 
leff3®Mllpolnl,comtQ) 

See item description fo r payment m ethods acce pted 
Online Payments [^[^[^ Credit Card» XZZi Electronic Check 
To use Online Payments noo 6-^ C 

•Seller ClfckMfi ^1124 > " * 
Will ship to United States only, See item description for shipping charges 
Seiien Didn't sell your item the first time? We will refund your relisting fee if it 
Relist item sells the second time around. Relist this item. 



High bid 
Payment 



Shipping 



Seller assumes ail responsibility for listing this item, you should contact the seller to resolve any 
questions before bidding. Auction currency is U.S. dollars ($) unless otherwise noted. 



FIG. 11 
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-1200 



I SECURE ONLINE PAYMENTS | g] 



Help 



Welcome, k@biilpoint.com! 



How to use Online Payments - 

Follow these easy steps once you know the high bidder wants to use 
Online Payments (here's howto find out.) 

1210 



Seller 



High Bidder 



receive 



lation email. 




Disc) ^3 Electronic Check 



Enter your Password to: 



• Send invoice for this item to a High Bidder 

• Viev/ or cancel the invoice (tf rt has not been paid) 

• View the Order Detail page or enter shipment tracldng information (if 
invoice has been paid). 

1240 

1 230 Usemame: K^blUpoinLcom 

^"^"^^ Password: I I 



(CANCEL) (CONTINUEj 



FIG. 12 
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I SECURE ONLIHE PAYMENTS \E\ 



Help 



Invoice Form 

Complete this invoice once you have determined the final amount due for 
this item including shipping fees or taxes, and you know the high bidder wants to 
use Online Payments. After you submit this Invoice, the buyer will 
automatically receive an e*mail with a link to begin payment. 

After the buyer pays for the item online, you will receive a payment confirmation e- 
mail notifying you that payment has cleared, if the buyer pays with a. 
credit card you should receive the confirmation e-mail immediately, if the buyer 
approximately 3-5 days. Then just ship the item! 

Enter BHIpoint Invoice Information 



Hem Name: Jar Jar Binks Doll ^1310 
Itemf: 504057950 ^1320 
^1330 



RnalAaction Price: |25!50 



Shipping, HandlInQ, & 
Insurance: 



Sales Tax: 10,00 I forttaan^'^^SO 
Buyer E-mall Address: |smrth@hotmail.com ^1360 
Buyer User ID: jsm'lth ^1370 ^qn^ 
^1382 ^^"^ 
Payment Methods: 0 Credit Card B Electronic Check 



More information on payment methods. 



Your Message: 

You may want to include a message to 
the buyer. 



Return Policy: 

Whythislsimportatnt 




(optional) Message must be less than 500 characters. 1388 




Please note: Billpoint strongly recommends that you include your Return Policy 
on this Invoice for your protection to help avoid disputes. 

Click the "REVIEV/ INVOICE" button below to view your Billpoint Invioce and 
confirm that it is correct before you submit it to the buyer. 



(cancel) (review invoice) ^1390 

~^ FIG. 13 



wo 01/71452 



PCTAJSOl/08293 



15/21 



-1400 



1430 




High Bidder - How Oniine Payments Worlcsuao 



Seller 



High Bidder 




receive 



ion email. 



Disc) ^3 Electronic Check 



To get strarted, the seller must send you a Invoice. If you haven't received an 

invoice, get a jumpstart by notifying the seller (with our easy-to-use fmail Ignudals) that 

you'd like to use Online Payments. \^_^ 

To pay for Item ©330390395 [Test item), log in below. ^ ^ 



^YoarllsfiUB; C 



J 



Ybu on Bin use yotir imxa address. 



'Your Password: [| 



Efuafltyoorpasswont? 



J 



Are you tired of typing in your User ID and Password over and over 
again? Save time by sianing in. (You may also sign In securely ). 



CANCEL CONTINUE 



FIG. 14 
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'1500 



I SECURE ONLINE PAYMEtfTS 1 6 1 Help 



Welcome to the new way to pay for your purchases! 

To pay for this item online, first review the Invoice 
Information below. 

r^l520 

If you have already registered, click here to pay In one step. ^ g-, q 
In voice 

ttemf: 504057950 

Item Name: (3) Jar Jar Binks Dolls 

Seller toystoystoys 

Date Invoice Sent 09A1 5/99 

Final AacUon Price: $25.50 

Shipping, Handling, & Insurance: $5.00 

SafesTax: $0.00 

Total Amount Due: $30.50 

Seller Message: You'll fove this!! 
Return Policy: AS Is condition 

Please dioose one of the following payment methods , or click "Cancel" to exit: 
(If only credit card is available:] 

Click "Pay with Credit Card' to pay for this item with a credit card, or click "Cancel** 
to exit 

[If only electronic check Is available:] 

Click "Pay with Electronic Check" to pay for this item using your checking account, 
or dick "Cancel" to exit 



( PAY WITH CREDIT CARD r ^^^ [^[^[mj 
C PAY WITH ELECTRONIC CHECK1 ^^^1560 
C CANCEL) 



FIG. 15 
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I SECURE ONUNE PAYMENTS | Bi \ Help 



Setter krauss@bIllpolnt*com Total Amoont 

Dae: $1.50 

Hem: Test Item 

Name: Item #: 33039035 

Enter New Credit Card Information and Place Your Order 



1610 



Please enter your credit card number and billing information into the secure form^ 
below. This information is kept confidential and will not be seen by the seller. 

Enter your credit card Information ^ 

All entries are required. 

Credit card: IVISA |vl 
Card Number | | 

Expiration: |Mav iv|l2002]v1 

Please enter your billing information as it appears on your credit card 
statement: 



Name: I iFir 
Billing Address: I Z 



C 

City:C 

State/Province/Region: C 



Please enter 2 tetter state code for US addresses (Ex. OA, HI) 



Zip/Postal Code: t i 

Country: tUnrted StatesTil 
Primary Phone Number: I i 

Ftease (nchide area code (Example: 123-456-7891) 
E-Mail Address: ieff3@billpoint.com 



Click "CONTINUE" to enter shipping information-your credit card is NOT charged 
at this time. To exit, click "CANCEL" 

(cancel) (continue ) 



FIG. 16 
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I SECURE ONLINE PAYMENTS | ^\ Help ^ ^^^^ 



Seller toystoystoys Total Amount Due: $30.50 

Item Name: Jar Jar BInks Doll item «: S040S7950 

Checking Account Information 
Please enter your payment information into the secure form below. This 
information is kept confidential and will not be seen by the seller. If you have 
questions on Electronic Checks, please see the Electronic Check FAQ for 

mm. 

Enter your Checking Account Information 

Please enter the checking account from which you would like to make this 
purchase. You can find the Bank Routing # and the Checking Account # on the 
bottom of the check, as shown in the example below. J 730 

Bank Nam e: ^ Bank Routing #:^1720 Checking Account #: 
1 I I I I I 

Sample Check (lower left comer) 



<^398118^^i2)CsL73136142^ 



TheBankRoutino#l5 The check I should match The Checking Account # is usually 
9 digits between the the # In the uppeprigiit comer to the left of «■ if check # is left 
i: i: symbols of account #, Ignore check #. 

Note: These three sets of numbers may appear tn a different order on your check. 

Enter your Name and Checkin Account Address ^1750 ' 

Please enter your name and the address where you receive statements for 



your checking account. 

Name: I inT 
Street Address: \ Z 



CilyrC 



State: [ 
Zip Code: 
Primary Phone Number: i i 

Please include area code (Example: 1 23-456-7891 ) 

Enter a Secondary Form of ldentHication^1760 

To protect the security of your checking account, you must provide a 
secondary fonn of identification. Please enter EITHER your Driver's License 
information OR your Social Security Number. 

Driver's Ucente: State luued: Date o f Birth: 

I I POOtll: I d I I 

") p (Example: 05/1 1/74) 

^1762 ^764 (^.ygg 

Social SeeortiyNnmbar: '1770 

^1768 

Click "CONTINUE" to enter vour shipping information-your checking account is1 
NOT charged at this time. To exit, click ^CANCEL" 



(CANCEL) (COMTINUE ) 

FIG. 17 
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r 




1 SECURE ONLINE PAYMENTS 1 fill Help 


Register 




Want to pay for your purchases in one step? 


Complete the short form below to save your payment information In a free 
online payment account Then just enter your password to pay in one easy step. 


Choose a Secure Password -i 820 

1810 Ij 
User ID: Password: 


1830 

V 

Retype Password: 


1 II 1 


1 1 


Enter Your Question and Your Secret Answer 


1850 


1840 

Secret Question: 




1 i 


1 1 


This fs the question we wifl ask you ff you forget our Password 
(Example: "Pers Namer 


Answer to the Secret Question 
(Example: "Rdo") 


By clicking the button below, you agree to the terms and conditions of the 
Participation Agreement and Privacv Police 


(CANCEL ACCOUNT SETUP) C FINISH ACCOUNT SETUP ) 



FIG. 18 
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1900 



I SECURE ONLINE PAYMENTS | £bl 



Thank you! Your payment has been initiated. 



Your electronic payment has been initiated. When your check payment 
has cleared, both you and the seller will be notified. 

This is your Order Receipt, You may want to print this page for your records. 
A confirmation e-mail has been sent to you at ismith@hotmafl,com. 

Your Order Receipt-Date Paid 09/15^9 ' 



Item #: 
Item Name: 
Seller 
Seller's E-mail: 
Total Paid: 



504057950 

jar jar binks doll 

toystoystoys 

toystoystoys@aol.com 

$30.50 



Ship to: 



Jay Smith 
100 Main St. 
San Francisco, CA 
94123 



Payment 
Metliod: 



Electronic Check 



FIG. 19 
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Instructions 
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r 
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